Release 10.1A: OpenEdge Getting Started:
Core Business Services

Resolving audit policy conflicts

You can create and activate one or more policies at the same time, for the same data. Multiple policies merge to create one run-time policy.

Because the policies that are merging might specify different data security levels, different event settings for the same event, or different table and field settings for the same table/field combination, a conflict might develop between or among active policies. At any time, you can run a report (using Audit Policy Maintenance) that identifies conflicts between or among active policies. This feature is especially useful because you can see if any conflicts exist before you commit changes to a policy.

Within a single database, multiple policies can be active, with different data security levels. The data security level used in each case will be taken from the active audit policy that the event or table is defined in, depending on the type of event.

When a policy merge occurs, the maximum data security level that applies in each case is used.

The rules are as follows:

Avoid conflicts.

Promote a best practice of avoiding conflicts as much as possible. Define event policy under a separate policy name to tables and field policy, and load only a single event policy for standard events. Break out your application events into separate policies. Do not load multiple active policies with duplicate table or field settings; keep things separate.

Always resolve conflicts to the maximum security or detail level.

In conflict situations, it is much safer to use a model that results in a higher security or detail level than anticipated than for the merge to result in a potential security breach or missing data.

Conflicting identifying fields will be aggregated.

If multiple active policies have the same table policy with different identifying fields, the identifying fields will be aggregated and the resultant full list will be used. If conflicting ordinal positions occur, the order in which the identifying fields will be placed into the audit context is unpredictable.

If table policy event IDs conflict, the first instance of the event ID takes precedence.

If multiple active audit policies define the same table policy with different event IDs specified for the create, read, update and delete file operations, it is unpredictable which will get used. The tools should avoid this situation, if possible, and report on it when it occurs. No run-time error will result; however, it will simply use the first event ID it finds for a specific file.

The audit event takes precedence over any table or field settings.

For table and field level events (for example, create, delete, and update), the audit event policy determines whether auditing is on or off for the event. If auditing is off for the event, the table and field policy settings are ignored.

Note that the level of detail on the event is irrelevant for table or field policy; it simply determines whether the event is on or off, as the detail level is defined for the table or field itself.

Within a single database, an event can have only a single setting.

An event is completely off, on with minimum details, or on with full details recorded. If the same event policy is found in multiple active audit policies in a database, the maximum level will be used for everything. This rule should always be resolved first to determine if auditing is on for the event or not, since the event takes precedence.

Within a single database, a table/field can have only a single setting.

If the same table or field is found in multiple active policies, then the maximum level will be used in each case. Note that when a table policy is defined, there is an implicit definition for all of the fields for that table with a level that matches the table level; any specific field definitions are exceptions.

Use the maximum data security level that applies in each case.

Within a single database, multiple policies can be active with different data security levels. The data security level used in each case will be taken from the audit policy that the event or table is defined in, depending on the type of event.

For table events (for example, create, update and delete), the data security level will come from the policy the table belongs to. For nontable events (for example, authentication) the data security level will come from the policy the event belongs to. For the data security level, fields are irrelevant because there is an implicit field definition for every field in a table.

Where a conflict occurs (for example, if the table or event is defined in more than one active policy), the maximum data security level from all the active policies the table or event is defined in will be used. For table events, a conflict situation develops only when the table is included in more than one policy; duplicate events are irrelevant, since the data security level is being used from the table’s policy.

For more information, see the Audit Policy Maintenance Help.